Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime

Summary

RCADA votes YES on Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime.

RCADA supports this proposal because it is a focused and materially improved resubmission of the earlier Scalus proposal.

RCADA previously abstained on Scalus: Cardano’s Application Platform for Building, Launching, and Scaling because the earlier request was too broad and too large, even though RCADA recognised the technical quality of Scalus, the credibility of Lantr Engineering, and the potential value of JVM-native Cardano developer infrastructure.

RCADA views this as a proportionate continuation of proven open-source developer infrastructure, with strong expectations around delivery evidence, adoption visibility, Dijkstra-readiness reporting, interoperability outputs, and bounded runtime scope.

Key Considerations

The proposal requests 2,464,844 ADA over 9 months.
The proposal uses a conservative $0.16/ADA reference rate and includes no contingency.
This is a reduced resubmission of the earlier Scalus proposal.
The previous proposal requested 8,503,000 ADA over 12 months.
The revised scope removes the standalone L1 node, full L2 integration, broad formal verification, and large platform-scale expansion.
The revised proposal focuses on maintenance, Dijkstra hard-fork readiness, interoperability, and a scoped application runtime step.
Scalus is open-source Cardano developer infrastructure built by Lantr Engineering.
Scalus is used directly by complex Cardano projects and indirectly through tooling used by other builders.
The proposal states that Scalus components are reused in MeshJS, Evolution SDK, Lucid Evolution, Cardano Client Lib, and YaciDevKit.
Lantr discloses prior Catalyst and Treasury funding and states that prior milestones were delivered and publicly reported.
The proposal uses audited SundaeSwap treasury contracts, independent oversight, third-party technical assurance, financial audit, public reporting, and automatic return of remaining funds after expiry.
RCADA sees the team’s response to DRep feedback as positive.
RCADA expects the application runtime work to remain bounded and not re-expand into the broader platform scope that DReps previously found too ambitious.

What this action does

This Treasury Withdrawal funds Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime, delivered by Lantr Engineering.

The total requested budget is:

Category	Amount
Development & Engineering	1,968,750 ADA
Product Management & Delivery	246,094 ADA
Documentation & Developer Enablement	156,250 ADA
Audits & Assurance	93,750 ADA
Total	2,464,844 ADA

The proposal funds a focused 9-month continuation across four areas:

maintenance of the existing Scalus stack and supported export targets;
Dijkstra hard-fork readiness across smart contracts, transaction building, emulation, and testing;
improved interoperability with existing Cardano tooling and the broader JVM, Java/Kotlin, and JavaScript/TypeScript ecosystems;
a scoped first step toward an application runtime.

The proposal excludes:

a production-grade JVM L1 node;
full Gummiworm L2 integration;
broad formal verification;
advanced devnet expansion;
large platform-scale expansion.

The proposal is structured across three quarterly milestones:

Milestone	Period	Focus
M1	Q3 2026	Continuity and Dijkstra preview
M2	Q4 2026	Interoperability and Dijkstra conformance
M3	Q1 2027	Dijkstra readiness and runtime consolidation

Funds are administered through the SundaeSwap treasury-contracts framework, with an independent oversight board, third-party technical assurance, financial audit, public reporting, public transaction journal, auto-abstain delegation, no SPO delegation, and automatic return of remaining funds after expiration.

Analysis Findings

Constitutional / Guardrails Assessment

✔ The proposal specifies a clear Treasury ask of 2,464,844 ADA.
✔ The proposal identifies the purpose of the withdrawal: Scalus maintenance, Dijkstra readiness, interoperability, and scoped runtime work.
✔ The proposal provides a 9-month delivery period.
✔ The proposal provides a clear budget breakdown.
✔ The proposal defines quarterly milestones and deliverables.
✔ The proposal discloses prior Catalyst and Treasury funding.
✔ The proposal states that the prior Treasury allocation was completed.
✔ The proposal includes independent oversight, third-party assurance, and financial audit.
✔ The proposal uses audited smart-contract escrow.
✔ The proposal enforces auto-abstain DRep delegation and no SPO delegation.
✔ The proposal includes an automatic sweep of remaining funds back to the Cardano Treasury.
✔ The proposal states that it does not exceed the applicable Net Change Limit at submission.
✔ The proposal is denominated in ADA.
⚠ Prior funding means continued support should depend on visible delivery and ecosystem value.
⚠ Dijkstra timing or specification changes may affect final readiness claims.
⚠ Runtime development should remain bounded and should not become unmanaged scope expansion.

Assessment: Constitutional pass with delivery, adoption, and scope-control expectations

Process & Governance Quality

✔ The proposal directly responds to DRep feedback on the previous Scalus proposal.
✔ The ask is materially smaller and the scope is more disciplined.
✔ The most contested items from the previous proposal have been removed.
✔ The proposal focuses on maintenance, protocol readiness, interoperability, and bounded runtime work.
✔ Lantr has disclosed prior funding and prior delivery history.
✔ The governance structure includes smart-contract escrow, independent oversight, technical assurance, financial audit, and public reporting.
✔ A public transaction journal improves auditability.
✔ The proposal includes measurable adoption indicators and quarterly reporting.
⚠ Scalus is specialised developer infrastructure, so adoption evidence matters.
⚠ JVM-native tooling is strategically useful, but not yet the dominant Cardano developer path.
⚠ The runtime component should be validated through reference applications, integration tests, and real builder feedback.
⚠ Reporting should distinguish developer-preview readiness from final hard-fork readiness if Dijkstra timelines shift.

Assessment: Strong improved resubmission with credible governance controls

Impact & Risk Analysis

Open-source developer infrastructure value: High
Dijkstra readiness value: High
Interoperability value: Medium to High
Application-runtime potential: Medium
Execution credibility: High
Treasury ask size: Medium
Adoption visibility risk: Medium
Runtime scope risk: Medium
Dijkstra timing/specification risk: Medium
Prior funding / recurring support risk: Medium
Administration/custody risk: Low
Strategic alignment: High

RCADA believes this proposal protects existing developer infrastructure, improves readiness for upcoming protocol changes, and broadens Scalus reuse across relevant developer ecosystems.

The main risks are around adoption visibility, Dijkstra timing uncertainty, and keeping the runtime work bounded. These are manageable risks given the reduced scope, prior delivery record, and strong oversight structure.

Assessment: Focused open-source infrastructure continuation / YES with adoption and delivery expectations

Ratings (Decision Support Only)

Dimension	Score (1–5)
Constitutional clarity	4
Governance quality	4
Execution credibility	4
Ecosystem value	4
Risk balance	4
Overall score	🟢 82% — YES for reduced, focused open-source developer infrastructure

RCADA Rationale

RCADA votes YES on Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime.

RCADA supports this proposal because it is a focused and materially improved resubmission of the earlier Scalus proposal. RCADA previously abstained on Scalus: Cardano’s Application Platform for Building, Launching, and Scaling because the earlier request was too broad and too large, even though RCADA recognised the technical quality of Scalus, the credibility of Lantr Engineering, and the potential value of JVM-native Cardano developer infrastructure.

This revised proposal directly addresses those concerns. The ask has been reduced from 8,503,000 ADA to 2,464,844 ADA, the duration has been reduced from 12 months to 9 months, the FTE commitment has been reduced from 8.25 to 2.25, and the most contested parts of the previous proposal have been removed from scope. The revised proposal no longer funds a standalone L1 node, full L2 integration, broad formal verification, or a large platform-scale expansion.

RCADA views this response to DRep feedback positively. Treasury governance should reward teams that listen, narrow scope, reduce risk, and resubmit stronger proposals. This version is more clearly focused on protecting existing public infrastructure, preparing for the Dijkstra hard fork, improving interoperability, and taking a bounded first step toward an application runtime.

RCADA supports the maintenance and Dijkstra-readiness components in particular. Scalus is already used directly by complex Cardano projects and indirectly through tooling used by other builders. Keeping that infrastructure maintained, compatible, and ready for protocol changes helps protect prior public investment and reduces disruption for teams that rely on Scalus components.

The interoperability work is also valuable. Cardano benefits from multiple developer pathways, and Scalus provides a JVM-native route for teams working in Scala, Java, Kotlin, and related enterprise backend environments. Improving reuse across JVM and JavaScript/TypeScript tooling can broaden Scalus’s practical value beyond teams that adopt the full Scalus stack directly.

RCADA also sees merit in the scoped application runtime, provided it remains bounded. Helping teams move from protocol development toward operating applications is a real ecosystem need. However, this runtime work should not become a backdoor expansion into the broader platform scope that DReps previously found too ambitious. RCADA expects this part of the work to be validated through reference applications, integration tests, and feedback from real users.

The proposal’s governance and accountability structure is strong. It uses audited SundaeSwap treasury contracts, an independent oversight board, third-party technical assurance through No.Witness Labs, independent financial audit, public quarterly reports, a public transaction journal, auto-abstain delegation, no SPO delegation, and automatic return of remaining funds after expiry.

RCADA also notes Lantr’s prior delivery record. The proposal discloses previous Catalyst and Treasury funding and states that all prior milestones were delivered and publicly reported. Prior funding should never create automatic entitlement to new Treasury funding, but delivery history is relevant when assessing execution credibility.

RCADA’s support comes with expectations. Scalus is specialised developer infrastructure, so ecosystem value should be demonstrated through visible delivery, integrations, downloads, repository activity, documentation, reusable examples, Dijkstra-readiness evidence, and feedback from active builders. Reporting should clearly distinguish developer-preview readiness from final hard-fork readiness if Dijkstra timelines or specifications change.

On balance, RCADA believes this revised proposal meets the standard for support. It is smaller, better scoped, more accountable, and more clearly aligned with open-source developer infrastructure than the previous version. It protects existing ecosystem tooling, responds constructively to prior governance feedback, and funds a proportionate continuation of proven work.